Since the invention of the microprocessor, integrated circuit densities have continued to increase, resulting in more powerful processors as well as more peripherals integrated onto the same chip. In recent years, complete "systems on a chip" have become available to serve processor intensive applications such as digital video or network communications in low cost consumer applications. FIG. 1 is a block diagram that illustrates the architecture of a commercially available microprocessor 10 (the STi5500 from SGS-Thomson Microelectronics) that exemplifies this high degree of integration. The STi5500 is a highly integrated chip with a RISC processor core and over a dozen on-chip peripherals needed to form a complete digital video system on a single chip. This microprocessor 10 provides a low cost solution for digital video applications such as satellite digital television receivers and digital video disk players. However, in order to create a "real-time" video signal from an encoded digital video stream, some processes must be performed in hardware and some in software, with great emphasis on synchronizing events. Accordingly, a real-time multitasking operating system is typically used with such a microprocessor 10.
As processors have become more powerful and more sophisticated peripherals have been integrated on chip, the demands of real-time multitasking operating systems have increased as well. Real-time multitasking operating systems, known also as real-time executives, have been prevalent for many years. Most real-time executives are designed for microprocessors and have special characteristics that are different from non-realtime operating systems. These characteristics include fast response time to external events, fast context switch time, deterministic operation, and preemptive and priority based scheduling. It is these characteristics that determine a real-time executive's system performance.
Most real-time executives are designed as software-only systems, taking advantage of a microprocessor's instruction set for performing the primitive functions that make up the building blocks of a real-time executive. A real-time executive generally consists of three parts: an application interface; executive functions; and kernel operations. The application interface provides a standard set of function calls used to manage both the task operations and other operating system services such as memory management or message handling. The executive functions are the operations that occur when a particular application interface function is invoked. Finally, at the core of the operating system, is the kernel. The kernel provides the primitive operations to manage multiple tasks and interrupts according to their assigned priorities and current state. The primary primitive functions of the kernel include context switching, scheduling, and critical section protection.
FIG. 2 is a conceptual block diagram of a software-only real-time executive architecture. Applications 90 execute on a processor 92 by accessing executive functions of a real-time executive 95 through an application programming interface (API) 100. The API 100 in turn enters a kernel 101 to perform scheduling or context switching functions. For preemptive events which occur asynchronously to the currently running task, an interrupt I/O mechanism 102 must be in place to allow kernel functions to be invoked while the processor is within an interrupt. While in an interrupt, kernel functions are called 103 using the API 100 in a reentrant manner.
U.S. Pat. No. 5,247,675 discloses a preemptive multipriority multitasking real-time operating system. This conventional software-based system is well represented in the art. Many microprocessors that are not dedicated to desktop computers run some type of real-time executive of a similar design.
Some real-time operating systems have been implemented such that some of the kernel primitive functions have been allocated to hardware circuitry, either as a component external to the processor or integrated within the processor's instruction set. For example, U.S. Pat. No. 4,964,040 discloses a computer hardware executive that is a special purpose associative processor. It serves as a real-time kernel and provides high speed executive functions such as task registration, task synchronization, scheduling, event handling, and buffer management. This hardware executive provides high speed and high performance kernel operations, but is not commercially viable for today's highly competitive markets, primarily due to the cost of the extra external chip. Additionally, the standalone hardware kernel cannot tightly integrate with on-chip peripherals seen on today's highly integrated processors that have signal processing, direct memory access, compression/decompression, and/or encoding/decoding functions.
The commercially available STi5500 microprocessor incorporates a hardware-only scheduler integrated into its instruction set. (That is, most portions of the hardware executive reside in the STi5500 processor's CPU, and the rest is part of a hardware executive API). The extended instruction set includes not only real-time executive functions and primitives, but also includes tight integration with peripherals so that scheduling activities can quickly and automatically occur without application intervention, once a hardware operation has completed and software processing needs occur immediately thereafter. The time it takes a system to respond to an event (usually a hardware event) and begin associated software processing is defined as "latency".
FIG. 3 is a conceptual block diagram of a hardware-only executive architecture 105, modeled on the STi5500 microprocessor. As with the software-only model shown in FIG. 2, the hardware-only model uses an API 106 to access executive functions. However, in this case, those executive functions are implemented as a hardware kernel 107 within the microprocessor itself, rather than in a software kernel 101. The diagram also shows two paths between the processor 92 and the kernel 107. The first path is a channel I/O 110 mechanism that can schedule processing automatically. The second path is a more traditional interrupt I/O 111 mechanism where an interrupt is generated by a hardware event, and a kernel function is called 112 through the API 106 in a reentrant manner in order to schedule processing or perform a kernel function.
The hardware executive processor architecture of FIG. 3 has been utilized in a family of integrated chips, all with the same CPU core, designed by SGS-Thomson Microelectronics. Numerous applications have used the hardware-based kernel. Experience with the hardware-based kernel has made it clear that a better task control executive is needed for the system. The problem with the hardware-only executive is that the system is not preemptive. For example, FIG. 4 is a block diagram that illustrates a system of multiple tasks using a CPU core of the type shown in FIG. 3. There are four execution spaces: high priority interrupts 120, a high priority execution queue 121, low priority interrupts 122, and a low priority execution queue 123. In terms of task priorities, there are only two, high and low. The high priority queue 121 executes round robin, and each task executes until it deschedules itself. When a high priority interrupt 120 occurs, and it needs to schedule processing, the hardware scheduler can only put the task or thread at the end of the high priority queue 121. Thus, all currently queued high priority threads must execute to completion before the new thread, as scheduled by the interrupt, can execute. The problem with this is that the latency between the hardware event and the processing to handle the event is often too large to acceptably process time-critical applications such as video decoding.
The low priority queue 123 differs from the high priority queue 121 in that it has a "timeslicing" component. If a task executes for longer than a timeslice period, the hardware scheduler automatically deschedules the task and goes on to the next task in the queue. Again, latency is a problem because the task that was timesliced will not execute again until all other queued threads in the low priority queue 123 have been executed and the queue has wrapped around to the timesliced task. In this case, the forced latency prevents the system from giving the remaining processor time to the non-realtime processor intensive tasks, slowing down the system throughput.
The problems above with the high and low priority queues are made worse in more highly integrated chips because there are more peripherals to manage and interface with. Also, the applications that these chips are currently targeted for include many traditional operating system features that require much more processor resources. Examples include file systems, network protocol stacks, Java language interpreters, and encryption/decryption. In addition to task management problems with the high and low priority queues, the hardware kernel 107 lacks some common and important facilities that are prevalent in many software-based executives. For example, the hardware kernel has timers and messages, but there is no message timeout. Also, software-based executives provide application layers that can be easily added, such as protocol stacks or file systems, whereas these would have to be recreated for a hardware-based kernel.
The many deficiencies described above led to the development by the present inventor of a software-based kernel hosted on a microprocessor having a "system on a chip" type of architecture (e.g., the STi55000 microprocessor) that was intended to solve all of the problems noted above. One design limitations was that the hardware scheduler could not be used, since it can automatically context switch without the knowledge of the software kernel, thus causing a loss of context. However, one implementation of such a software-based kernel design was found not to provide the performance necessary for certain peripherals. Additionally, there were peripherals that required the use of channel I/O 110 rather than interrupt I/O 111. This was a critical problem because channel I/O 110 requires the use of the scheduler function of the hardware kernel 197, which was disallowed with that implementation of the software-based executive. These problems with hosting a software-based scheduler on such a chip were an unexpected discovery and presented a fundamental problem to solve in order to have any viable products based on the chip.
The possible performance gains of permitting hardware scheduler operations are illustrated in FIGS. 5, 6, and 7. FIG. 5 is a timing diagram that illustrates a standard path beginning with a hardware event and finishing with a task performing processing in response to the hardware event for a software-based executive. (The relative times are derived from an analysis of a current version of the STi5500 microprocessor and are exemplary only.) The sequence begins with the hardware inducing an interrupt 130 that preempts task processing 134. The interrupt 130 first executes a kernel interrupt entry call 131, then executes a kernel service call 132 (such as a semaphore). Next, an interrupt exit call 133 is executed. With the assumption that the kernel service call 132 requires scheduling, the interrupt 130 is exited and revectoring 135 is performed to enter the kernel scheduler. Finally, kernel scheduling 136 is completed and the corresponding task begins executing 137 in response to the interrupt 130 induced by the hardware event. Using the fastest kernel call and with no other latencies, such as a high priority task or a higher priority interrupt, the hardware event to software processing latency time is about 45 .mu.S best case.
If hardware scheduling is allowed for the fastest real-time events, the channel I/O 110 and interrupt I/O 111 hardware scheduling methods can be used. FIG. 6 is a timing diagram that illustrates the sequence of execution that is performed automatically by a hardware scheduler upon the receipt of a channel I/O 110 event. When the channel event 140 occurs, low priority processing 141 is preempted. When the channel event 140 completes, the hardware scheduler 142 context switches to event processing 143 that was waiting for the channel I/O event. In this case, the hardware event to software processing latency time is about 0.5 .mu.S best case, nearly 100 times faster than the software-only kernel latency time.
For peripherals that do not support channel I/O, the interrupt I/O 111 method of event processing is used. FIG. 7 is a timing diagram that shows the sequence of execution for interrupt I/O using a hardware executive. When an interrupt event occurs 150, the low priority task is preempted 151 and an interrupt service routine begins processing. The interrupt service routine makes a hardware executive service call 152 and then the interrupt service routine exits 153. The hardware scheduler 154 then switches context to the event processing routine 155 that was waiting for the hardware executive service call 155 (e.g., a semaphore). The interrupt event to software processing for this case is around 6 .mu.S, which is still around 7 times faster than the software-based executive model of FIG. 5.
In summary, a central problem in the art is that using a hardware scheduler alone causes one type of latency, and using a software scheduler alone causes a different type of latency. Each of the types of latencies can cause errors in the signal processing, causing potential errors in the resultant output (e.g., dropouts in a video signal). Further, certain hardware peripherals require the use of a hardware scheduler for data transfer, even if it is desirable to use software scheduling for other functions and general ease of use. However, because of the problems described above, to the best of the inventor's knowledge, the art has not taught how to effectively combine a software-based executive with a hardware-based executive, particularly for a "system on a chip" type of microprocessor.
The inventor has determined that it would be highly useful to be able to utilize a hardware-based executive on a "system on a chip" type of microprocessor while still being able to take advantage of the functions of a software-based executive. Accordingly, a general object of the present invention is to permit a software-based executive to execute concurrently with a hardware-based executive.
Another object of the invention is to minimize latencies in hardware-based executive interrupts and tasks caused by a software-based executive.
A further object of the invention is to integrate with the hardware executive API for the creation and management of hardware executive interrupts and tasks.
Still another object of the invention is to integrate the software-based executive interrupt management with the hardware-based executive interrupt management and associated API. In other words, both the hardware and software executives should have the same interrupt management, functions, and API.
Yet another object of the invention is to provide a mechanism that allows hardware-based executive tasks and interrupts to communicate with software-based tasks.